Processing systems are typically capable of performing processing tasks to enable processed signals to be visually and/or audibly perceivable. This will be discussed by way of example with reference to FIG. 1.
FIG. 1 shows a typical processing system 100 which includes a number of system layers 102, a system directory 104 and an input portion 106. In general, the input portion 106 and the system directory 104 can be coupled to the system layers 102.
The system layers 102 can include an applications layer 102a, an engine layer 102b, a library layer 102c, an operating system layer 102d and an output layer 102e. 
The applications layer 102a can be coupled to the engine layer 102b. The engine layer 102b can be coupled to the library layer 102c. The library layer 102d can be coupled to the operating system layer 102d. The operating system layer 102d can be coupled to the output layer 102e. The operating system layer 102d can be further coupled to the applications layer 102a and the system directory 104.
Furthermore, as shown, the input portion 106 can be coupled to the applications layer 102a. 
In an exemplary scenario, the processing system 100 can correspond to an electronic device operable to play a game. Further, the processing system 100 can be based on an Android® based operating system (OS). Specifically, the processing system 100 can correspond to a portable electronic device such as a Smartphone and the input portion 106 can be a touch sensitive screen which is capable of sensing touch from a user.
In this regard, the applications layer 102a can be related to a game based application, the engine layer 102b can be a game engine, the library layer 102c can be related to an Open Graphics Library and the operating system layer 102d can be related to an Android® based OS layer.
For example, a user can play a game on the electronic device by touching the input portion 106. Therefore, user touch sensed by the input portion 106 can be considered to be input signals. The input signals can be processed by the input portion 106 and communicated to the applications layer 102a. The processed input signals can be communicated to the applications layer 102a to control, for example, game play (e.g., events and/or actions) as the game progresses.
Game based applications (i.e., at the applications layer 102a) typically rely on game engines (i.e., at the engine layer 102b) for processing tasks which are graphics and/or audio related.
Operationally, the applications layer 102a can be configured to generate and communicate application signals to the engine layer 102b based on input signals received from the input portion 106. Additionally, as will be discussed later in further detail, the applications layer 102a can be configured to generate and communicate a load request signal to the operating system layer 102d (as signified by arrow 110).
The engine layer 102b can be configured to receive and process the application signals to produce engine signals. For example, the engine layer 102b can be configured to receive and process application signals in a manner so as to extract metadata. Metadata can, for example, relate to movement of movable game characters in a game and/or appearance of game characters in a game. In this regard, metadata can, for example, correspond to the engine signals.
The engine layer 102b can be further configured to communicate the engine signals to the library layer 102c. 
The library layer 102c can, for example, correspond to an application programming interface (API) for the purpose of rendering two dimensional (2D) and/or three dimensional (3D) electronic graphics. One such example is OpenGL® which is an industry standard for computer graphics with defined APIs. The API can be based on a system file which can be loaded from the system directory 104.
Earlier mentioned, the applications layer 102a can be configured to generate and communicate a load request signal to the operating system layer 102d. Based on the load request signal received, the operating system layer 102d can generate and communicate an instruction signal to the system directory 104 (as signified by arrow 112). Based on the instruction signal received, the system directory 104 can load (as signified by arrow 114) a system file, which resides in the system directory 104, to the library layer 102c. The system file can have a system file name. The system file name can be associated with a file name which is unique only to the load request signal.
Therefore, the library layer 102c can be configured to receive and process the engine signals based on the system file to produce library signals. The library layer 102c can be further configured to communicate the library signals to the operating system layer 102d for further processing to produce driver signals. The operating system layer 102d can be further configured to communicate the driver signals to the output layer 102e for driving the output layer 102e so that visual and/or audible perception is possible. In this regard, the output layer 102e can, for example, correspond to a display screen and/or speaker driver(s).
In one example, each of the movable game characters can be associated with a fundamental appearance which can be visually perceived via the output layer 102e. In another example, each of the movable game characters can also be associated with a fundamental audio track (e.g., soundtrack/sound effect) which can be audibly perceived via the output layer 102e. 
Hence each of the movable game character(s) can be associated with a fundamental property/attribute which can be in relation to one or both of the fundamental appearance and the fundamental audio track.
Appreciably, conventional processing techniques associated with the typical processing system 100 do not facilitate processing in an efficient and/or user friendly manner. Specifically, conventional processing techniques do not facilitate modifications to the aforementioned fundamental property in an efficient and/or user friendly manner.
In one example, even though processed input signals can be communicated to the applications layer 102a to control, game play (e.g., events and/or actions) as the game progresses, it is appreciable that the fundamental appearance associated with a game character does not change. For example, a game character can be associated with an appearance of an apple. Hence the fundamental appearance of the game character is an apple and processed input signals can be communicated to control movement of the apple during game play. However, the fundamental appearance of the game character being controlled remains an apple despite change in location of the game character during game play.
In this regard, if modifications to the fundamental appearance of the game character are desired, there may be a need to modify game sourcecode and/or release packages (i.e., at/prior to the applications layer 102a).
Therefore, conventional processing techniques do not facilitate modifications to the aforementioned fundamental property in an efficient and/or user friendly manner and it is hence desirable to provide a solution to address at least one of the foregoing problems.